Conferencing architecture employing media servers and enhanced session initiation protocol

ABSTRACT

A conferencing system that can acess advanced conferencing features while following essentially the same call flow as conventional conferencing systems. The conferencing system includes a computer network, and at least one conferencing application server, at least one media server, and at least one user agent connected to the network. The conferencing application server establishes and manages multimedia conferences by engaging in Session Initiation Protocol (SIP) signaling with the user agents and the media server. Once the conference is established, the media server generates multimedia data such as audio data and conveys the data to the conference participants. In order to access advanced conferencing features, the conferencing system employs an enhanced SIP signaling technique including a conferencing Application Programming Interface (API) implemented by incorporating Extensible Mark-up Language (XML) messages in the bodies of respective SIP request/response messages. The XML messages are incorporated in the SIP request/response message bodies to convey conference specific commands and/or parameters that cannot be easily described via the Session Description Protocol (SDP).

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority of U.S. Provisional PatentApplication No. 60/303,837 filed Jul. 9, 2001 entitled CONFERENCINGARCHITECTURE EMPLOYING MEDIA SERVERS AND ENHANCED SESSION INITIATIONPROTOCOL.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[0002] N/A

BACKGROUND OF THE INVENTION

[0003] The present invention relates generally to conferencing systems,and more specifically to techniques for accessing enhanced conferencingcapabilities.

[0004] Conferencing systems are known that employ the Session InitiationProtocol (SIP) to establish and manage multimedia sessions (also knownas “conferences”) over computer networks. For example, a conferencehaving zero or more conference participants may be established over anetwork by a conferencing application server, which communicates witheach conference participant and at least one media server on the networkusing SIP call control signaling. In the event a prospective conferenceparticipant wishes to join the conference, the prospective participantsends a SIP request message to the conferencing application server.After receiving the SIP request message, the conferencing applicationserver sends a corresponding SIP request message to at least one mediaserver assigned to the conference.

[0005] In the event the conference Universal Resource Identifier (URI)exists on the media server, the media server sends a SIP 200 OK messageto the conferencing application server to indicate that the prospectiveconference participant has been successfully joined to the conference.If the conference URI does not exist on the media server, then thedesired conference is created before the media server sends the SIP 200OK message. The conferencing application server then sends acorresponding SIP 200 OK message to the conference participant toindicate the participant's success in joining the conference. Next, theconference participant sends a SIP ACK message to the conferencingapplication server to acknowledge its receipt of the SIP 200 OK message,and the conferencing application server sends a corresponding SIP ACKmessage to the media server. Because the prospective conferenceparticipant has successfully joined the conference, a multimedia sessionis established during which multimedia data such as audio data isgenerated and conveyed between the media server and the conferenceparticipant.

[0006] In the event the conference participant wishes to be removed fromthe conference, the participant sends a SIP BYE request message to theconferencing application server, which in turn conveys the SIP BYErequest to the media server. Next, the media server sends a SIP 200 OKmessage to the conferencing application server, which in turn conveysthe SIP 200 OK message to the conference participant, thereby indicatingthat the participant has been successfully removed from the Conference.In this way, the conferencing application server can both create amultimedia conference and control prospective conference participants'access to the conference.

[0007] Although the above-described SIP call control signaling techniquemay be employed to establish and manage multimedia conferences, thetechnique has drawbacks in that it is generally not amenable toestablishing and managing conferences that provide advanced conferencingfeatures such as notification of conference events (e.g., theidentification of conference participants whose voices are mixed intothe audio output of the conference) or packet mixing for determining thescope of multimedia data delivery within a conference. Theabove-described technique also provides no mechanism for detecting andreporting media events such as DTMF/MF digits input by conferenceparticipants. Such events are commonly used to invoke advancedconferencing features. This is because conventional SIP call controlsignaling techniques employing SIP INVITE/BYE request messages typicallydo not provide interfaces that can easily access such advancedconferencing features.

[0008] It would therefore be desirable to have a conferencing system forestablishing and managing multimedia conferences over computer networks.Such a conferencing system would employ enhanced call control signalingtechniques to provide a conferencing application server/media serverinterface capable of accessing advanced conferencing features It wouldalso be desirable to have a conferencing system that can access advancedconferencing features while following essentially the same call flow asconventional conferencing systems.

BRIEF SUMMARY OF THE INVENTION

[0009] In accordance with the present invention, a conferencing systemis provided that can access advanced conferencing features whilefollowing essentially the same call flow as conventional conferencingsystems. Benefits of the presently disclosed conferencing system areachieved by employing a conferencing application programming interfacebased on the Extensible Mark-up Language (XML) in conjunction withSession Initiation Protocol (SIP) call control signaling to createfull-featured conferencing applications.

[0010] In one embodiment, the conferencing system comprises a computernetwork including a signaling plane and a media plane, and at least oneconferencing application server, at least one media server, and at leastone user agent communicably connected to the network. The conferencingapplication server is configured to establish and manage at least onemultimedia conference by engaging in SIP signaling with one or more ofthe user agents wishing to participate in the conference and the mediaserver in the signaling plane of the network. Once the multimediaconference is established, the media server generates multimedia datasuch as audio data and conveys the data to the conference participantsin the media plane of the network.

[0011] In the presently disclosed embodiment, the conferencing systememploys a SIP INVITE signaling method to create the multimediaconference and subsequently join prospective participants to theconference. The conferencing system also employs a SIP BYE signalingmethod to remove participants from the conference and/or terminate theconference. In order to access advanced conferencing features that maybe inaccessible via conventional SIP call control signaling methods, theconferencing system employs an enhanced SIP signaling techniqueincluding a conferencing Application Programming Interface (API) thatfacilitates the interaction between the conferencing application serverand the media server in the network signaling plane. The enhanced SIPsignaling technique including the conferencing APT is implemented byincorporating XML messages, and messages based on the SessionDescription Protocol (SDP), in the bodies of respective SIP request andresponse messages. The XML messages are incorporated in the SIPrequest/response message bodies to convey conference specific commandsand/or parameters that cannot be easily described via the SDP.

[0012] By incorporating XML payloads into SIP requests/responses tosignal the addition of advanced conferencing features, the conferencingsystem can provide advanced conferencing capabilities withoutsignificantly modifying the signal and media flows through the network.

[0013] Other features, functions, and aspects of the invention will beevident from the Detailed Description of the Invention that follows.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

[0014] The invention will be more fully understood with reference to thefollowing Detailed Description of the Invention in conjunction with thedrawings of which:

[0015]FIG. 1 is a block diagram of a conferencing system capable ofaccessing advanced conferencing features according to the presentinvention;

[0016]FIG. 2 is a call flow diagram illustrating the creation of athree-way conference using the conferencing system of FIG. 1; and

[0017]FIG. 3 is a call flow diagram illustrating the creation of aconference having advanced conferencing features using the conferencingsystem of FIG. 1.

DETAILED DESCRIPTION OF THE INVENTION

[0018] U.S. Provisional Patent Application No. 60/303,837 filed Jul. 9,2001 entitled CONFERENCING ARCHITECTURE EMPLOYING MEDIA SERVERS ANDENHANCED SESSION INITIATION PROTOCOL is incorporated herein byreference.

[0019] A conferencing system is disclosed that is capable of accessingadvanced conferencing features, which cannot be easily accessed viaconventional call control signaling methods. The presently disclosedconferencing system accesses such advanced conferencing features via aconferencing application programming interface that allows enhanced callcontrol signaling techniques.

[0020]FIG. 1 depicts an illustrative embodiment of a conferencing system100 capable of accessing advanced conferencing features, in accordancewith the present invention. In the illustrated embodiment, theconferencing system 100 comprises a computer network 101 including asignaling plane 108 and a media plane 110. The signaling plane 108includes signaling control legs 112.1-112.n, 114, and 116, and the mediaplane 110 includes media conference legs 118.1-118.n. The conferencingsystem 100 further includes at least one conferencing application server102, at least one media server 104, and one or more user agents106.1-106.n. As shown in FIG. 1, the conferencing application server102, the media server 104, and the user agents 106.1-106.n are connectedto respective control legs in the signaling plane 108 of the network,while only the media server 104 and the user agents 106.1-106.n areconnected to respective conference legs in the media plane 110 of thenetwork. It is understood that the computer network 101 may comprise aLocal Area Network (LAN), a Wide Area Network (WAN), the Internet, orany other network suitable for providing conferencing services.

[0021] The conferencing application server 102 is configured to createat least one multimedia session (“conference”), enable prospectiveconference participants to join the conference, and manage the overalloperation of the conference within the conferencing system 100. Themedia server 104 is configured to provide requested conferencingservices to the conference participants, which may comprise one or moreof the user agents 106.1-106.n. Each user agent 106.1-106.n is capableof requesting admission to/removal from the conference, and engaging inthe multimedia session with the media server 104.

[0022] It is understood that the conferencing application server 102,the media server 104, and the user agents 106.1-106.n compriserespective components in the computer network 101 such as servercomputers, client computers, or software processes running on networknodes. It is further understood that the user agents 106.1-106.n maycomprise Internet devices such as SIP phones and/or non-Internet devicessuch as Public Switched Telephone Network (PSTN) phones. For example,one or more of the user agents 106.1-106.n may comprise a PSTN phoneconfigured to access the conference through a PSTN/Internet Protocol(IP) gateway device.

[0023] Moreover, the conferencing application server 102, the mediaserver 104, the user agents 106.1-106.n, and the gateway may compriserespective logical devices, two or more of which may be included in thesame physical device. For example, the conferencing application server102 and one of the user agents 106.1-106.n may comprise respectivelogical devices included in the same SIP phone or desktop computer(e.g., a WINDOWS XP™ SIP client and a media player). Alternatively, theconferencing application server 102, the media server 104, and thePSTN/IP gateway may comprise respective logical devices included in thesame conferencing server device. The conferencing application server102, the media server 104, and the user agents 106.1-106.n are depictedin FIG. 1 as separate devices for clarity of discussion.

[0024] Specifically, the conferencing application server 102 creates oneor more conferences and manages the overall operation of the conferencesby engaging in call control signaling using a predetermined signalingprotocol with one or more of the user agents 106.1-106.n and the mediaserver 104 in the signaling plane 108 of the network 101. In thepresently disclosed embodiment, the predetermined signaling protocol isthe Session Initiation Protocol (SIP), however, it is understood thatany suitable signaling protocol for session initiation may be employed.The Session Initiation Protocol is described in Internet EngineeringTask Force (IETF) Request For Comments (RFC) 2543 (1999), which isincorporated herein by reference. As shown in FIG. 1, the conferencingapplication server 102 engages in SIP signaling with the user agents106.1-106.n over the respective control legs 112.1-112.n, and with themedia server 104 over the control leg 116, in the signaling plane 108.As a result, the media server 104 is conceptually invisible to the useragents 106.1-106.n in the network signaling plane 108.

[0025] Further, the media server 104 generates and conveys multimediadata such as audio data over the conference legs 118.1-118.n in themedia plane 110 of the network 101 according to the Real Time TransportProtocol (RTP) or any other suitable protocol for transmittingmultimedia data. The Real Time Transport Protocol is described in IETFRFC 1889 (1996), which is incorporated herein by reference. In thepresently disclosed embodiment, the conferencing application server 102is not involved in the processing of media flows between the mediaserver 104 and the respective user agents 106.1-106.n in the networkmedia plane 110.

[0026] The media server 104 is further configured to provide notice ofasynchronous events (e.g., the identification of conference participantswhose voices are mixed into the audio output of the conference) over atleast one control leg in the signaling plane 108, e.g., the control leg114, which may comprise a HyperText Transfer Protocol (HTTP) sidechannel. In alternative embodiments, the media server 104 may employ SIPINFO or NOTIFY signaling methods over a suitable control leg, e.g., thecontrol leg 116, to provide notice of such asynchronous events to theconferencing application server 102.

[0027] As described above, the conferencing application server 102 isconfigured to create one or more multimedia conferences within theconferencing system 100, and enable prospective conference participantsto join the conferences. In the presently disclosed embodiment, theconferencing application server 102 employs a SIP INVITE signalingmethod to create a conference and join prospective participants to theconference, and a SIP BYE signaling method to remove conferenceparticipants from the conference.

[0028] The SIP INVITE/BYE signaling methods employed by the conferencingapplication server 102 will be better understood with reference to thefollowing first illustrative example and FIG. 2. In this first example,Participant 1 (e.g., the user agent 1.06.1; see FIG. 1) represents aprospective conference participant wishing to join a multimediaconference. To that end, Participant 1 sends a SIP request message 202(see FIG. 2) to the Control Agent (e.g., the conferencing applicationserver 102; see FIG. 1) over a signaling control leg indicating itsdesire to join the conference, which is identified by a publicconference Universal Resource Identifier (URI). Universal ResourceIdentifiers are described in IETF RFC 2396 (1998), which is incorporatedherein by reference.

[0029] For example, the SIP request URI for the desired conference mayhave the following format:

[0030] sip:conf=uniqueIdentifier@mediaserver.carrier.net,

[0031] in which “conf” indicates to a Media Server (e.g., the mediaserver 104; see FIG. 1) that conferencing services are requested,“uniqueIdentifier” is a suitable value compliant with the URIspecification, and “mediaserver.carrier.net” identifies the MediaServer. It is noted that it is the responsibility of the conferencingapplication running on the conferencing application server to ensurethat the SIP request URI for the conference is unique so as to avoidpotential Universal Resource Identifier conflicts.

[0032] After receiving the SIP request message 202, the Control Agentsends a corresponding SIP request message 204 to the Media Server overthe signaling control leg. In this illustrative example, the SIP requestmessage 204 is directed to a non-public conference URI identifying thedesired conference. In this way, network security is enhanced becausethe non-public portion of the SIP control interface for the conferenceis not exposed to Participant 1 or any other prospective conferenceparticipant. It is noted that network security can be further enhancedby providing a secure link between the Control Agent and the MediaServer to prevent unauthorized entities from creating conferences on theMedia Server. For example, security mechanisms that may be employed toprovide the secure link between the Control Agent and the Media Serverinclude authenticated SIP, Access Control Lists (ACLs), or any othersuitable security mechanism.

[0033] In the event the Media Server fails to recognize the conferenceURI because the URI does not currently exist on the Media Server, theMedia Server creates the desired conference according to the SessionInitiation Protocol. If the conference URI already exists on the MediaServer, then the Media Server sends a SIP 200 OK message 206 to theControl Agent to indicate that Participant 1 has been successfullyjoined to the conference. The Control Agent then sends a correspondingSIP 200 OK message 208 to Participant 1, and a SIP ACK message 210 tothe Media Server to acknowledge its receipt of the SIP 200 OK message206. Next, Participant 1 sends a SIP ACK message 212 to the ControlAgent to acknowledge its receipt of the SIP 200 OK message 208. Becausethe desired conference has been successfully created and Participant 1has been successfully joined to the conference, an RTP session 214 isestablished to allow multimedia data such as audio data to be generatedand conveyed between Participant 1 and the Media Server over a suitablemedia conference leg.

[0034] In this illustrative example, if Participant 1 wishes to beremoved from the conference, then Participant 1 sends a SIP BYE requestmessage 216 to the Control Agent, which then conveys a SIP BYE requestmessage 218 to the Media Server. Next, the Media Server sends a SIP 200OK message 220 to the Control Agent, which in turn conveys a SIP 200 OKmessage 222 to Participant 1 to indicate that Participant 1 has beensuccessfully removed from the conference.

[0035] It should be appreciated that the SIP INVITE/BYE signalingmethods in the above-described first illustrative example may beemployed to manage relatively simple conferencing applications such asapplications that use the default conferencing parameters provisioned onthe Media Server. For example, a relatively simple conferencingapplication may comprise a 3-way calling application involving threeconference participants (e.g., Participants 1-3 of FIG. 2) with noadvanced conferencing features. In such simple conferencingapplications, required conference specific commands and/or parametersare typically incorporated in the bodies of SIP request and/or SIPresponse messages using the Session Description Protocol (SDP).

[0036] In order to access advanced conferencing features that arenormally inaccessible via conventional SIP call control signalingtechniques, the conferencing system 100 (see FIG. 1) employs an enhancedSIP signaling technique including a conferencing Application ProgrammingInterface (API) that facilitates the interaction between theconferencing application server 102 and the media server 104 in thenetwork signaling plane 108. The enhanced SIP signaling techniqueincludes incorporating at least one command in a predetermined payloadformat in the bodies of SIP request and/or SIP response messages toconvey conference specific commands and parameters that cannot be easilydescribed using the SDP. In the presently disclosed embodiment, thepredetermined payload format is a form of the Extensible Mark-upLanguage (XML). It is understood, however, that any suitable form of XMLor non-XML language (e.g., a suitable binary representation or textscripting language) may be employed. It is noted that the formaldefinition of the document structure, i.e., the XML Document TypeDefinition (DTD), for the XML messages incorporated in the SIPrequests/responses is herein referred to as “MediaServerXML”.Accordingly, the conference specific commands and/or parameters forachieving enhanced conferencing control are incorporated in the bodiesof SIP request/response messages as MediaServerXML payloads.

[0037] Specifically, the presently disclosed conferencing API exploitsthe ability of the Session Initiation Protocol to carry payloads asmulti-part MIME message bodies. In the presently disclosed embodiment,the MIME type used to describe the MediaServerXML payloads is“application/xml”. Further, each MediaServerXML payload typicallycomprises a single request or response, and the size of eachMediaServerXML payload is approximately equal to that of a typical SDPpayload.

[0038] As in the first example above, SIP request messages incorporatingMediaServerXML payloads are conveyed in the conferencing system 100 fromthe conferencing application server 102 to the media server 104 via theSIP INVITE signaling method. In the presently disclosed embodiment, eachSIP request message carries at least one MediaServerXML payload.Further, in order to simplify the development of the conferencingapplication and reduce the size of the MediaServerXML payload, one ormore of the MediaServerXML request attributes may take on default valuesor be defined as “#IMPLIED”, thereby allowing these attributes to beomitted from the request if they are subsequently not needed.

[0039] Moreover, at least one MediaServerXML payload can be carried fromthe media server 104 back to the conferencing application server 102 inthe body of a SIP response message (e.g., a SIP 200 OK message)corresponding to the above-mentioned SIP request message. In thepresently disclosed embodiment, MediaServerXML payloads carried by SIPresponse messages are defined in the XML DTD using a relatively simpleand concise form of XML that makes limited use of nesting. This makesthe SIP response messages easier to parse, which obviates the need for afull XML parser on the conferencing application server 102.

[0040] It is noted that conferencing applications can be configured tosubscribe to event notifications using MediaServerXML commands. Forexample, MediaServerXML commands included in SIP request messages may beemployed to specify events of interest (e.g., the identification ofconference participants whose voices are mixed into the audio output ofthe conference) and how notifications of these events are to beperformed. Moreover, the event notifications may be delivered via HTTP(e.g., over the control leg 114; see FIG. 1) or using the SIP INFO orSIP NOTIFY signaling methods (e.g., over the control leg 116; see FIG.1). If the event notifications are delivered via HTTP, the conferencingapplication may employ a MediaServerXML command to define a UniformResource Locator (URL) as the target for the HTTP request (i.e., the“http/get” request, as mentioned below), and the format of the eventinformation. Further, the conferencing application may use theabove-described uniqueIdentifier and a SIP Call ID to tie the HTTP eventnotification to the corresponding conference.

[0041] The presently disclosed conferencing API enables enhanced SIPsignaling techniques to perform conferencing functions including but notlimited to creating a conference, modifying a conference, joiningparticipants to a conference, modifying a conference leg, playing audio,recording audio, and the detection and notification of media events suchas DTMF/MF digits. It should be appreciated that these conferencingfunctions are described below for purposes of illustration.

[0042] Creating a Conference

[0043] An enhanced SIP signaling technique employed by the conferencingsystem 100 (see FIG. 1) to create a conference will be better understoodwith reference to the following second illustrative example and FIG. 3.It is noted that the conference is created using a dedicated control legthat has no associated media flow. This ensures that the conferenceremains in existence even if one or more of the conference participantsleaves the conference.

[0044] As shown in FIG. 3, Participant 1 (e.g., the user agent 106.1;see FIG. 1) sends a SIP request message 302 to the Control Agent (e.g.,the conferencing application server 102; see FIG. 1) to create theconference. After receiving the SIP request message 302, the ControlAgent sends a corresponding SIP request message 304 to a Media Server(e.g., the media server 104; see FIG. 1) over the dedicated control leg(e.g., the signaling control leg 116; see FIG. 1).

[0045] In accordance with the presently disclosed conferencing API, theSIP request messages 302 and 304 (see FIG. 3) comprise MediaServerXMLpayloads including conference specific commands and parameters forcreating the desired conference. For example, a MediaServerXML payloadincluding the following XML request message (“<create_conference>”) maybe employed to request the creation of a conference having up to ten(10) conference participants (or more if sufficient resources areavailable), and to subscribe to the “join” and “leave” conferenceevents: <?xml version=“1.0”?> <MediaServerXML version=“1.0”> <request><create_conference maxparties=“10”> <subscribe method=“http/get”target=http://appserver.provder.net/cgi/conf.pl?conf=$ conf&amp;leg=$leg&amp; event=$event&amp; value=$value> <events> <join/> <leave/></events> </subscribe> </create_conference> </request></MediaServerXML>.

[0046] In this second example, the variables $conf, $leg, $event, and$value are expanded to form a URL comprising the target for the http/getrequest. Specifically, the $conf variable is set to the value of theunique conference identifier specified by the conferencing applicationin the SIP request URI (i.e., $conf=uniqueIdentifier). This provides away of associating the conference with event notifications sent on theHTTP side channel. Further, the $leg variable is set to the unique SIPCall ID for the leg on which the event occurred. Moreover, the $eventvariable describes the type of event that occurred (e.g., the “join” or“leave” conference event). Finally, the $value variable includes thevalue associated with the event. Because there is no value associatedwith either one of the “join” or “leave” conference events, the $valuevariable is empty in this example.

[0047] Next, the Media Server sends a SIP 200 OK response message 306 tothe Control Agent over the dedicated control leg to indicate that thedesired conference has been successfully created. In the presentlydisclosed embodiment, a SIP response message issued in response to a SIPrequest message including at least one MediaServerXML payload may alsoinclude at least one MediaServerXML payload. For example, the followingXML response message may be employed in the SIP 200 OK message 306:<?xml version=“1.0”?> <MediaServerXML version=“1.0”> <responserequest=create_conference code=“200” text=“OK” /> </MediaServerXML>,

[0048] in which “code=‘200’” indicates that the <create_conference> XMLrequest is successfully completed. The Control Agent then sends a SIPACK message 308 to the Media Server to acknowledge the receipt of theSIP 200 OK message 306.

[0049] In order for Participant 1 to join the existing conference, theControl Agent sends a SIP request message 310 to the Media Server, whichsends a SIP 200 OK response message 312 to the Control Agent to indicatethat Participant 1 has been successfully joined to the conference. TheControl Agent then sends a SIP 200 OK response message 314 toParticipant 1. Next, Participant 1 sends a SIP ACK message 316 to theControl Agent, which in turn sends a SIP ACK message 318 to the MediaServer, thereby acknowledging the receipt of the SIP 200 OK messages 312and 314. As a result, an RTP session 320 is established betweenParticipant 1 and the Media Server over a suitable media conference leg.

[0050] In the event Participant 1 wishes to leave the conference, SIPBYE request messages 322 and 324 are sent, and SIP 200 OK messages 326and 328 are generated, as similarly described with reference to thefirst example above. It should be appreciated that additional conferenceparticipants such as Participants 2-3 may be joined to/removed from theconference, in accordance with the call flow depicted in FIG. 3.

[0051] Modifying a Conference

[0052] In the presently disclosed embodiment, the conferencingapplication server 102 (see FIG. 1) is capable of modifying an existingconference by sending a SIP “re-INVITE” request message including an XMLrequest message with conference parameters for modifying the conferenceto the media server 104. For example, the following XML message(“<modify_conference>”) may be included in the body of a SIP re-INVITErequest message to change the size of an existing conference to 14conference participants: <?xml version=“1.0”> <MediaServerXMLversion=“1.0”> <request> <modify_conference maxparties=“14” /></request> </MediaServerXML>.

[0053] It is noted that the <modify_conference> XML message can be usedeven if the conference were not created using the above-mentioned<create_conference> XML message. As a result, the conferencingapplication can modify conference parameters regardless of the initialconferencing requirements.

[0054] Moreover, the following illustrative XML message may be includedin the body of a SIP response message issued in response to the aboveSIP request message including the illustrative <modify_conference> XMLmessage: <?xml version=“1.0”> <MediaServerXML version=“1.0”> <responserequest=“modify_conference” code=“200” text=“OK” /> </MediaServerXML>,

[0055] in which “code=‘200’” indicates that the <modify_conference> XMLrequest is successfully completed.

[0056] Joining Participants to a Conference

[0057] As described above, one or more conference participants may bejoined to a conference by directing a suitable SIP request message tothe conference URI. In order to provide advanced conferencing featureswhile joining the conference participants, an XML message requesting theadvanced conferencing features is included in the body of the SIPrequest message. For example, the following XML message (“<add_leg>”)may be included in the SIP request message body to add a leg to anexisting conference: <?xml version=“1.0”?> <MediaServerXMLversion=“1.0”> <request> <add_leg mixmode=“parked” toneclamp=“no”><subscribe method=“http/get”target=http://appserver.provider.net/cgi/cont.pl?conf=$ conf&amp;event=$event&amp; value=$value> <events> <digits collectmask=“6789”numdigits=“1”/> </events> </subscribe> </add_leg> </request></MediaServerXML>.

[0058] It is noted that the above <add_leg> XML message includesconference parameters for providing advanced mix-mode and tone-clampconferencing features and notification of specific Dual ToneMulti-Frequency (DTMF) events. Further, as described above, thevariables $conf, $leg, $event, and $value are expanded to form a URLcomprising the target for the http/get request. Moreover, in this XMLrequest message, the $event variable is set to “DTMF”, and the $valuevariable includes a corresponding DTMF digit string.

[0059] Modifying a Conference Leg

[0060] In the presently disclosed embodiment, the conferencingapplication server 102 (see FIG. 1) is capable of modifying an existingconference leg (e.g., changing the packet mixing mode or eventsubscription) by sending a SIP re-INVITE request message including anXML message with conference parameters for modifying the leg to themedia server 104. For example, the following XML message(“<modify_leg>”) may be included in the body of a SIP re-INVITE requestmessage to change the packet mixing mode: <?xml version=“1.0”><MediaServerXML version=“1.0”> <request> <modify_leg mixmode=“listen”></modify_leg> </request> </MediaServerXML>.

[0061] For example, the illustrative <modify_leg> XML message above maybe used to change the packet mixing mode to “listen” to assure that themultimedia data input of the conference participant on that leg is“muted” and not mixed into the conference.

[0062] Playing Audio

[0063] In the presently disclosed embodiment, there are at least two SIPcall control signaling methods for playing audio within the conferencingsystem 100 (see FIG. 1). The first call control signaling methodrequires at least one new or existing conference leg having anassociated media flow. The scope of the audio data within the conferenceis determined by the current mix-mode setting for that conference leg.Specifically, a mix-mode value of “preferred” indicates that the audioinput from the conference leg is to be mixed and delivered to all of theconference participants, and a mix-mode value of “parked” indicates thatthe conference leg's audio Input/Output (I/O) are isolated from theconference. For example, the mix-mode may be set using either the<add_leg> or <modify_leg> XML request message, as described above. It isnoted that in order to play audio data to the entire conference, the“virtual” attribute on the conference leg is set to “yes”. Finally, aSIP re-INVITE request message including a MediaServerXML payload“<play>” (as described below) is sent to the media server 104.

[0064] The “parked” mix-mode is useful when an announcement or anInteractive Voice Response (IVR) script is desired before joining aprospective conference participant to the conference. Specifically, asingle SIP request message directs the prospective participant to theconference, but completely isolates the prospective participant from theconference. After the announcement or the IVR script is completed, theconferencing application sends a SIP request message including a<modify_leg> XML message to enable the prospective participant to jointhe conference. This reduces the amount of SIP signaling between theconferencing application server 102 and the prospective conferenceparticipant because there is no need to first “INVITE” the prospectiveparticipant to the conference and then re-INVITE the participant to theconference.

[0065] The second call control signaling method can be used to playaudio to the entire conference. It is noted, however, that the secondsignaling method requires a conferencing system with a dedicated controlleg having no associated media flow. Specifically, the conferencingapplication sends a SIP re-INVITE request message including the <play>XML message (as described below) to the Media Server over the dedicatedcontrol leg. Because there is no media flow associated with thededicated control leg, it is understood that the audio is to be playedto the entire conference.

[0066] For example, the following <play> XML message may be included inthe body of a SIP request message sent by the conferencing applicationserver 102 to the media server 101 to play audio data within theconferencing system 100 (see FIG. 1): <?xml version=“1.0”><MediaServerXML version=“1.0”> <request> <playurl=http://audio.provider.net/greeting.g711 encoding=“ulaw” /><subscribe method=“http/get” target=“http://appserver.provider.net/cgi/conf.pl?conf=$co nf&amp; event=$event&amp; value=$value”><events> <done/> </events> </subscribe> </request> </MediaServerXML>.

[0067] It is noted that the <play> XML message has two attributes,particularly, a first attribute specifying the source URL of the audiodata (“url=http://audio.provider.net/greeting.g711”) and a secondattribute that specifies the encoding of the audio data(“encoding=‘ulaw’”). Further, in order to receive notification that theaudio playing is completed, the <play> XML message subscribes to the“<done>” event, as shown above. In this case, the value of $event is“done”, and $value includes a text string describing how the <play>request completed, e.g., End of File (EOF).

[0068] Recording Audio

[0069] In the presently disclosed embodiment, the SIP call controlsignaling methods employed to record audio data are similar to theabove-described signaling methods used to play audio. For example, themix-mode for a particular conference leg may be set to “listen”, and thevirtual attribute on the conference leg may be set to “yes”, usingeither the <add_leg> or <modify_leg> XML request message. Next, a SIPre-INVITE request message including a MediaServerXML payload “<record>”(see below) is sent to the media server 104. For example, the following<record> XML message may be included in the body of a SIP requestmessage sent by the conferencing application server 102 to the mediaserver 104 to record audio data within the conferencing system 100 (seeFIG. 1): <?xml version=“1.0”> <MediaServerXML version=“1.0”> <request><record url=“file:////audio/conf.gsm” encoding=“ms_gsm” /> <subscribemethod=“http/get”target=“http://appserver.provider.net/cgi/conf.pl?conf=$conf&amp;event=$event&amp;value$=value”> <events> <done/> </events></subscribe> </request> </MediaServerXML>.

[0070] In alternative embodiments, the conferencing application mayissue the <record> XML request message on a dedicated control leg havingno associated media flow. Because no media flow is associated with thededicated control leg, it is understood that the entire conference audiooutput is to be recorded. It is noted that local URLs using the “file://. . . ” format may be used to identify the location of the source of therecording. Alternatively, the HTTP format may be employed.

[0071] In order to receive notification that the audio recording iscompleted, the conferencing application subscribes to the <done> event,as shown above. In this case, the value of the $event variable is“done”, and the value of the $value variable includes text describinghow the <record> request completed, e.g., “end_silence” indicating thattrailing silence was detected.

[0072] It will further be appreciated by those of ordinary skill in theart that modifications to and variations of the above-describedconferencing architecture may be made without departing from theinventive concepts disclosed herein. Accordingly, the invention shouldnot be viewed as limited except as by the scope and spirit of theappended claims.

What is claimed is:
 1. A conferencing system, comprising: a computernetwork; and a plurality of logical devices communicably connected tothe network, a first logical device being configured to establish atleast one conference and to control access of one or more prospectiveconference participants to the conference, at least one second logicaldevice being configured to request access to and to participate in theconference, and at least one third logical device being configured toprovide at least one conferencing service to the conferenceparticipants, wherein the first logical device is further configured toengage in call control signaling with at least one of the second andthird logical devices, the call control signaling employing apredetermined signaling protocol for session initiation and comprisingconveying at least one request message including at least one command ina predetermined payload format to access at least one feature of theconferencing services provided by the third logical device.
 2. Theconferencing system of claim 1 further including first and secondphysical devices communicably connected to the network, the firstphysical device including the first and second logical devices, and thesecond physical device including the third logical device.
 3. Theconferencing system of claim 1 further including first and secondphysical devices communicably connected to the network, the firstphysical device including the second logical device, and the secondphysical device including the first and third logical devices.
 4. Theconferencing system of claim 1 wherein the second logical devicecomprises a logical gateway device, and further comprising a physicaldevice including the first, second, and third logical devices.
 5. Theconferencing system of claim 1 wherein the third device is configured toconvey at least one response message based on the predeterminedsignaling protocol to the first device over the network in response tothe request message conveyed by the first device for accessing theconferencing service feature, the response message including at leastone command in the predetermined payload format.
 6. The conferencingsystem of claim 1 wherein the computer network includes a signalingplane and a media plane, the first device being connected to thesignaling plane, and each of the second and third devices beingconnected to the signaling plane and the media plane.
 7. Theconferencing system of claim 6 wherein the first device is configured toconvey at least one request message including at least one command inthe predetermined payload format to the third device over a signalingcontrol leg in the signaling plane to access the conferencing servicefeature provided by the third device.
 8. The conferencing system ofclaim 7 wherein the signaling control leg comprises a dedicated controlleg having no associated media.
 9. The conferencing system of claim 6wherein the second device is configured to convey at least one requestmessage including at least one command in the predetermined payloadformat to the first device over a signaling control leg in the signalingplane to request access to the conference.
 10. The conferencing systemof claim 9 wherein the third device is configured to convey multimediadata to the second device over a media conference leg in the media planein the event the second device is provided access to the conference bythe first device.
 11. The conferencing system of claim 6 wherein thefirst device is configured to convey at least one request messageincluding at least one command in the predetermined payload format tothe third device over a first signaling control leg in the signalingplane to request notification of at least one event.
 12. Theconferencing system of claim 11 wherein the third device is configuredto convey notification of at least one conference event to the firstdevice over an HTTP side channel in the signaling plane.
 13. Theconferencing system of claim 11 wherein the third device is configuredto convey notification of at least one conference event to the firstdevice via a SIP signaling method in the signaling plane.
 14. Theconferencing system of claim 11 wherein the third device is configuredto convey notification of at least one media event to the first deviceover an HTTP side channel in the signaling plane.
 15. The conferencingsystem of claim 11 wherein the third device is configured to conveynotification of at least one media event to the first device via a SIPsignaling method in the signaling plane.
 16. The conferencing system ofclaim 11 wherein the third device is configured to convey notificationof the at least one conference event to the first device over a secondsignaling control leg in the signaling plane by engaging in call controlsignaling using the predetermined signaling protocol for sessioninitiation.
 17. The conferencing system of claim 6 wherein the firstdevice is configured to convey at least one request message including atleast one command in the predetermined payload format to the thirddevice over a signaling control leg in the signaling plane to requestestablishment of the conference.
 18. The conferencing system of claim 6wherein the first device is configured to convey at least one requestmessage including at least one command in the predetermined payloadformat to the third device over a signaling control leg in the signalingplane to request modification of at least one feature of the conference.19. The conferencing system of claim 6 wherein the first device isconfigured to convey at least one request message including at least onecommand in the predetermined payload format to the third device over asignaling control leg in the signaling plane to request modification ofat least one feature of a media conference leg in the media plane. 20.The conferencing system of claim 6 wherein the first device isconfigured to convey at least one request message including at least onecommand in the predetermined payload format to the third device over asignaling control leg in the signaling plane to request playing of audiodata over at least one media conference leg in the media plane.
 21. Theconferencing system of claim 20 wherein the first device is configuredto convey at least one request message including at least one command inthe predetermined payload format to the third device over a dedicatedcontrol leg having no associated media to request the playing of audiodata over each media conference leg in the media plane.
 22. Theconferencing system of claim 6 wherein the first device is configured toconvey at least one request message including at least one command inthe predetermined payload format to the third device over a signalingcontrol leg in the signaling plane to request recording of audio dataover at least one media conference leg in the media plane.
 23. Theconferencing system of claim 1 wherein the predetermined signalingprotocol for session initiation is the Session Initiation Protocol(SIP).
 24. The conferencing system of claim 1 wherein the predeterminedpayload format is a form of the Extensible Mark-up Language (XML). 25.The conferencing system of claim 1 further including a securecommunications link disposed between the first and third logicaldevices.
 26. A method of operating a conferencing system, theconferencing system including a computer network and a plurality oflogical devices communicably connected to the network, comprising thesteps of: establishing at least one conference and controlling access ofone or more prospective conference participants to the conference by afirst logical device communicably connected to the network; requestingaccess to the conference for subsequent participation therein by atleast one second logical device communicably connected to the network;and providing one or more conferencing services to the conferenceparticipants by at least one third logical device communicably connectedto the network, wherein the steps of establishing and controllingfurther include engaging in call control signaling with at least one ofthe second and third logical devices by the first logical device, thecall control signaling employing a predetermined signaling protocol forsession initiation and comprising conveying at least one request messageincluding at least one command in a predetermined payload format toaccess at least one feature of the conferencing services provided by thethird logical device.
 27. The method of claim 26 further including thestep of conveying at least one response message based on thepredetermined signaling protocol to the first device over the network bythe third device, the response message being conveyed in response to therequest message conveyed by the first device for accessing theconferencing service feature, the response message including at leastone command in the predetermined payload format.
 28. The method of claim26 wherein the step of engaging further includes conveying at least onerequest message including at least one command in the predeterminedpayload format to the third device by the first device, the requestmessage being conveyed over a signaling control leg in a signaling planeof the network to access the conferencing service feature provided bythe third device.
 29. The method of claim 26 wherein the step ofengaging further includes conveying at least one request messageincluding at least one command in the predetermined payload format tothe first device by the second device, the request message beingconveyed over a signaling control leg in a signaling plane of thenetwork to request access to the conference.
 30. The method of claim 29wherein the step of engaging further includes, in the event the seconddevice is provided access to the conference by the first device,conveying multimedia data to the second device over a media conferenceleg in a media plane of the network by the third device.
 31. The methodof claim 26 wherein the step of engaging further includes conveying atleast one request message including at least one command in thepredetermined payload format to the third device by the first device,the request message being conveyed over a first signaling control leg ina signaling plane of the network to request notification of at least oneevent.
 32. The method of claim 26 wherein the step of engaging furtherincludes conveying at least one request message including at least onecommand in the predetermined payload format to the third device by thefirst device, the request message being conveyed over a signalingcontrol leg in a signaling plane of the network to request establishmentof the conference.
 33. The method of claim 26 wherein the step ofengaging further includes conveying at least one request messageincluding at least one command in the predetermined payload format tothe third device by the first device, the request message being conveyedover a signaling control leg in a signaling plane of the network torequest modification of at least one feature of the conference.
 34. Themethod of claim 26 wherein the step of engaging further includesconveying at least one request message including at least one command inthe predetermined payload format to the third device by the firstdevice, the request message being conveyed over a signaling control legin a signaling plane of the network to request modification of at leastone feature of a media conference leg in a media plane of the network.35. The method of claim 26 wherein the step of engaging further includesconveying at least one request message including at least one command inthe predetermined payload format to the third device by the firstdevice, the request message being conveyed over a signaling control legin a signaling plane of the network to request playing of audio dataover at least one media conference leg in a media plane of the network.36. The method of claim 35 wherein the step of engaging further includesconveying at least one request message including at least one command inthe predetermined payload format to the third device by the firstdevice, the request message being conveyed over a dedicated control leghaving no associated media to request the playing of audio data overeach media conference leg in the media plane.
 37. The method of claim 26wherein the step of engaging further includes conveying at least onerequest message including at least one command in the predeterminedpayload format to the third device by the first device, the requestmessage being conveyed over a signaling control leg in a signaling planeof the network to request recording of audio data over at least onemedia conference leg in a media plane of the network.